If you have any questions about how to structure your changes feel free to ping me over slack as I was the primary author of the new LIR support for barriers.

If you have any questions about how to structure your changes feel free to ping me over slack as I was the primary author of the new LIR support for barriers.

Thanks, Tom! I will do that whenever I get stuck or have questions. So far I'm making progress. Structurally, Shenandoah will be look like a mix of ZGC (for the load-barrier, even though I am modeling it as a Node that consumes the loaded value, instead of replacing the ReadNode altogether) and G1 (for the SATB parts), and likely Serial/Parallel for the card-table parts.

Sounds good. There's still some more work to finish out the switch to LIR only barriers but I think supporting G1 and ZGC covers the required strategies in a fairly pragmatic way.

@tkrodriguez can you please take another look at this. Once done, we can ask @davleopo and @gergo- to look at it.

I'll take a look.

Are the gate failures actual problems? It would be good to see a clean gate. Also, we should squash the history before committing.

Are the gate failures actual problems? It would be good to see a clean gate.

I don't know what those problems are. I fixed everything that looked related to my changes. Those failures look like infra problems, some volumes seem to have run out of memory or something. I doubt that it is related.

Also, we should squash the history before committing. Ok, I can do that - tomorrow.

@tkrodriguez There seem to be GHA failures that report SerialWriteBarriers not being Lowerable, coming from SubstrateVM. Could this be related to moving the barrier addition phase from mid- to low-tier? I don't think I have changed anything in SerialWriteBarrier or related code.

Yes this is something I mentioned in our slack discussions. Moving WriteBarrierAdditionPhase after LowTierLoweringPhase creates problems for GCs that still use snippets since they expect to be lowered by LowTierLoweringPhase. In the long term I would like it to be done there but I'm not sure how to bridge the gap. I've got an internal PR based on your branch that I'm testing and I was going to look into this.

The options are to conditionalize the placement of WriteBarrierAdditionPhase based on methods from BarrierSet but that's not available when constructing the suites. We could have early and late WriteBarrierAdditionPhase to handle each case during the transition but that's a bit ugly to me. Or we could beef up WriteBarrierAdditionPhase to perform any required lowering itself, though that might be a bit complicated. It would also complicate stuff like BarrierSetVerificationPhase and some barrier elimination that's part of enterprise.

I'm going to try putting appendPhase(new PlaceholderPhase<>(WriteBarrierAdditionPhase.class)); in both MidTier and LowTier and do the placeholder replacement based on the BarrierSet.

Yes this is something I mentioned in our slack discussions. Moving WriteBarrierAdditionPhase after LowTierLoweringPhase creates problems for GCs that still use snippets since they expect to be lowered by LowTierLoweringPhase. In the long term I would like it to be done there but I'm not sure how to bridge the gap. I've got an internal PR based on your branch that I'm testing and I was going to look into this.

The options are to conditionalize the placement of WriteBarrierAdditionPhase based on methods from BarrierSet but that's not available when constructing the suites. We could have early and late WriteBarrierAdditionPhase to handle each case during the transition but that's a bit ugly to me. Or we could beef up WriteBarrierAdditionPhase to perform any required lowering itself, though that might be a bit complicated. It would also complicate stuff like BarrierSetVerificationPhase and some barrier elimination that's part of enterprise.

I'm going to try putting appendPhase(new PlaceholderPhase<>(WriteBarrierAdditionPhase.class)); in both MidTier and LowTier and do the placeholder replacement based on the BarrierSet.

As far as I can see, it's only the SerialWriteBarrierNode which depends on snippets (is that right?). That should be relatively straightforward to implement without snippets and would look almost exactly like ShenandoahCardBarrierNode implementation - even a little simpler. I could work on implementing that, if you think that'd help.

It would be easy to convert the HotSpot serial barrier to LIR but native image uses snippets for its barriers and its serial barrier is non-trivial. So we'll need to live with this mixed model for a little while I think. I'm beginning to think we might just need an early and late phase. I think the way barriers for vector writes work, we might have to do barrier addition for them before LowTierLowering, or at least before VectorLoweringPhase, which is before FixReadsPhase.

It might be too much to try to resolve all these issues in this PR. Since Shenandoah is currently HotSpot only maybe it would be best to special case its barrier insertion. I'll will play some more with this to see what would be best.

It would be easy to convert the HotSpot serial barrier to LIR but native image uses snippets for its barriers and its serial barrier is non-trivial. So we'll need to live with this mixed model for a little while I think. I'm beginning to think we might just need an early and late phase. I think the way barriers for vector writes work, we might have to do barrier addition for them before LowTierLowering, or at least before VectorLoweringPhase, which is before FixReadsPhase.

It might be too much to try to resolve all these issues in this PR. Since Shenandoah is currently HotSpot only maybe it would be best to special case its barrier insertion. I'll will play some more with this to see what would be best.

I implemented barrier addition to trigger in both mid- and low-tier, and the BarrierSet implementation gets to choose which one (or both, if it wishes) is appropriate. This choice defaults to mid-tier, and can be overridden in implementations, like I did in ShenandoahBarrierSet. This way we get a clean gate :-)

Thanks. I'll see whether that works ok in our full gate. I'd tried something slightly different but the StageFlags makes it hard to be super flexible about when these phases run. I might be tempted to keep only the phase that actually does the work in the final suite.

Your fix works though I don't love some of the details. I'll just put comments on those places. I was able to get a clean internal gate with just minor changes in enterprise. I wasn't actually able to test Shenandoah because we don't have a labsjdk that includes it at the moment.

Overall I think this looks good. I've only lightly reviewed the actual shenandoah parts since I don't really know anything about how the collector works. A high level JavaDoc comment on each of your newly added classes would be appreciated.

@davleopo @gergo- I think it's in good shape for review.

Thanks very nice work, looks pretty ready I did not see any blockers from my side. I added some style/unification comments. One question is if we should already add necessary SyncPort annotations to the jdk code in question to capture changes asap.

I forgot to mention here is the SyncPort class we use it to denote hot spot ports. When the upstream implementation changes we are informed in our internal testing.

I've started doing some gate testing and found one problem.

mx benchmark renaissance:finagle-http -- -XX:+UseShenandoahGC -Xmx8g

throws a lot of exceptions like this and never completes

[finagle/netty4-2-23] WARN io.netty.channel.ChannelOutboundBuffer - Failed to mark a promise as success because it has succeeded already: Http2CodecUtil$SimpleChannelPromiseAggregator@4e30b251(uncancellable)
[finagle/netty4-2-23] WARN io.netty.util.concurrent.DefaultPromise - An exception was thrown by io.netty.handler.codec.http2.AbstractHttp2StreamChannel$Http2ChannelUnsafe$3.operationComplete()
java.lang.IllegalStateException: complete already: DefaultChannelPromise@23f179c2(uncancellable)
	at io.netty.util.concurrent.DefaultPromise.setSuccess(DefaultPromise.java:100)
	at io.netty.channel.DefaultChannelPromise.setSuccess(DefaultChannelPromise.java:78)
	at io.netty.channel.DefaultChannelPromise.setSuccess(DefaultChannelPromise.java:73)
	at io.netty.handler.codec.http2.AbstractHttp2StreamChannel$Http2ChannelUnsafe.writeComplete(AbstractHttp2StreamChannel.java:1084)
	at io.netty.handler.codec.http2.AbstractHttp2StreamChannel$Http2ChannelUnsafe.access$2100(AbstractHttp2StreamChannel.java:630)
	at io.netty.handler.codec.http2.AbstractHttp2StreamChannel$Http2ChannelUnsafe$3.operationComplete(AbstractHttp2StreamChannel.java:1061)
	at io.netty.handler.codec.http2.AbstractHttp2StreamChannel$Http2ChannelUnsafe$3.operationComplete(AbstractHttp2StreamChannel.java:1055)
	at io.netty.util.concurrent.DefaultPromise.notifyListener0(DefaultPromise.java:590)
	at io.netty.util.concurrent.DefaultPromise.notifyListeners0(DefaultPromise.java:583)
	at io.netty.util.concurrent.DefaultPromise.notifyListenersNow(DefaultPromise.java:559)

mx unittest -XX:+UseShenandoahGC jdk.graal.compiler.hotspot.test.GCBarrierEmissionTest shows several problems. On aarch there's a cbnz with size 8 but it should be 32 I think.

java.lang.AssertionError: 8
	at jdk.graal.compiler/jdk.graal.compiler.asm.aarch64.AArch64MacroAssembler.cbnz(AArch64MacroAssembler.java:1768)
	at jdk.graal.compiler/jdk.graal.compiler.hotspot.aarch64.shenandoah.AArch64HotSpotShenandoahLoadRefBarrierOp.lambda$emitCode$0(AArch64HotSpotShenandoahLoadRefBarrierOp.java:192)
	at jdk.graal.compiler/jdk.graal.compiler.lir.LIRInstruction$LIRInstructionSlowPath.emitSlowPathCode(LIRInstruction.java:78)
	at jdk.graal.compiler/jdk.graal.compiler.lir.asm.CompilationResultBuilder.emitSlowPath(CompilationResultBuilder.java:589)

and jdk.graal.compiler.hotspot.test.GCBarrierEmissionTest#getAndSetBarrier produces an unschedulable graph.

This test might be useful for you to look more closely at. I'd originally written it as a testbed for the ZGC port. It's designed so that you can compare the output of C2 and Graal for all the core barrier patterns. See https://github.com/oracle/graal/blob/master/compiler/src/jdk.graal.compiler.test/src/jdk/graal/compiler/hotspot/test/GCBarrierEmissionTest.java#L53. I have a little utility to split each nmethod dump into it's own file so you can do pairwise comparison if you are interested in that.

One ugly missing piece is support for the fast truffle dispatch in the truffle implementation of EntryPointDecorator.emitEntryPoint. That code performs an explicit read of an obj in the method prologue assembly, so it might need special handling. See https://github.com/oracle/graal/blob/master/compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/truffle/hotspot/amd64/AMD64TruffleCallBoundaryInstrumentationFactory.java#L59 and https://github.com/oracle/graal/blob/master/compiler/src/jdk.graal.compiler/src/jdk/graal/compiler/truffle/hotspot/aarch64/AArch64TruffleCallBoundaryInstrumentationFactory.java#L58. Hopefully it's fairly easy to support that. We hope to eliminate that extra read in https://bugs.openjdk.org/browse/JDK-8358006